X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C93619.8C0D18DD@onstor-exch02.onstor.net>; Fri, 24 Oct 2008 13:46:10 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C93619.8C0D18DD"
Content-class: urn:content-classes:message
Subject: RE: Lun Label type-5 Functional Spec. for Kegg
Date: Fri, 24 Oct 2008 13:46:10 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E038F9143@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0C19CB37@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Lun Label type-5 Functional Spec. for Kegg
Thread-Index: Ack0pDOGwsjJ1gNkTEyXhNf4IHF7KQAiul2wAAEHxdAAAFt/oAAAU/bAAAMjlBAACggvEAAkeWsQAAaYmmA=
From: "James Kahn" <james.kahn@onstor.com>
To: "Deepak Veliath" <deepak.veliath@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>,
	"dl-Kegg" <dl-Kegg@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C93619.8C0D18DD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



_____________________________________________
From: Deepak Veliath=20
Sent: Friday, October 24, 2008 10:30 AM
To: dl-Design Review; dl-Kegg
Subject: RE: Lun Label type-5 Functional Spec. for Kegg

Hello Jim,
From your responses it would seem that "lun show disk" will not list the
new partitions/extents as separate entities but simply show a larger
sized LUN with the same device_name, is that correct?  And any new Lun
extents can only belong to the volume that the first extent belongs to?

At the moment, all extents are owned by the volume.  The "lun show ..."
command does not own the label information
and can only report the full capacity of the LUN.  There is provision
for a list of volumes owning the LUN to be displayed
as a future extension.

The intent of the next phase would be to have a volume own LUN extents
rather than entire LUNs.  Which would
pave the way for multiple volumes in a LUN.  Still have some details to
resolve before that stage of development.

So when a "volume show VOLNAME" command is invoked, the size displayed
against each LUN will be the sum of the sizes of the extents in use by
the volume on that LUN (even if they are not contiguous)?

Yes, that is correct.  However, this functionality is for the next phase
of development.
I have several areas to refactor to eliminate the 1 LUN contains 1
VOLUME assumption.
LUN discovery is built with this assumption.  Ditto for auto-grow.

When a volume is deleted do we intend to coalesce any LUN extents to
obtain a single extent?  If so will this affect our volume undelete
feature?

When a volume is deleted, any extent used is marked free.  Undelete
walks the extents and
has to identify which ones were used by the volume for undelete.  Now,
if the LUN is used to
create a new volume, the free extents are coalesced.  You cannot
undelete after that.


Also how will adding new space to a LUN to a free LUN extent that
previously contained a volume, affect our volume undelete feature?

Now that is an interesting issue.  Currently, undeleted volume would
come back as a bigger volume if it is the
last free extent.  If it was not the last free extent, then it would
come back with the same size.

Regards,
Jim







	Hello Jim,
*	From reading the spec I understand you are making space appended
to a physical LUN accessible by exporting them as partitions or as you
call them, LUN extents.  What would the device IDs for these partitions
be as displayed by "lun show disk"?

		There are various defined extent (aka volume) types
define.  Thus far, all we really do is give the allocated extent
		to a volume.  There are several details to be ironed out
before multiple extents become extensively used.
		That will be an issue for a future functional spec.
Perhaps we should talk about future direction on this subject...

*	From the Figure 10 it would seem there is only a single owner
block for the whole physical LUN.  Does this mean that only a single
node in a cluster can access the partitions at any given time.

		The idea is to provide a well-known location for the
owner block so outcluster access can be controlled as well as
		Limiting access by other nodes in the cluster.

*	If a partition has no FS on it, does it make to append space
added to the physical LUN to be added directly to the partition?

		At this time the last free extent of the LUN would own
any expanded capacity added to a LUN.  This is the up-side
		of variable-size LUN extents.  (The down-side is
fragmentation.  That becomes an issue once multiple extents=20
		are being used.)

		 If a volume was already created using the LUN, it would
not suddenly get the new capacity.  On down the road, auto-grow would be
updated to allow the volume to grow into the expanded LUN capacity. This
is fairly straight forward for a single LUN volume.  A bit more
complicated for a multi-lun volume.   And I would think that customers
would want a policy knob to control this behavior.

*	Regd Solaris disk-labels, AFAIK on an Intel based system Solaris
creates a PC MBR, allocates the whole disk (skipping the 1st track) to a
primary partition of type 0x82 and slices that partition up using its
native partitioning logic which I believe is very similar to the BSDs.
So I believe we're safe on x86 systems running Solaris (which in turn
means Leopards can co-exist with Cougars on the SAN?).

	Yes, if Sun honors PC MBR labels, then the new type-5 LUNs we
can co-exist.

	This new label has lots of headroom for future growth,
	JIm

------_=_NextPart_001_01C93619.8C0D18DD
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: Lun Label type-5 Functional Spec. for Kegg</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma">_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">From:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Deepak Veliath<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Sent:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Friday, October 24, 2008 =
10:30 AM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">To:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> dl-Design Review; =
dl-Kegg<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></B></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> RE: Lun Label type-5 Functional Spec. for =
Kegg</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Verdana">Hello Jim,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Verdana">From your responses it would seem that &quot;lun show =
disk&quot; will not list the new partitions/extents as separate entities =
but simply show a larger sized LUN with the same</FONT></SPAN><SPAN =
LANG=3D"en-us"><I></I></SPAN><SPAN LANG=3D"en-us"><I> <FONT =
COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Verdana">device_name</FONT></I></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" =
SIZE=3D2 FACE=3D"Verdana">, is that correct?&nbsp; And any new Lun =
extents can only belong to the volume that the first extent belongs =
to?</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">At the moment, all extents are owned by the volume.&nbsp; =
The</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">&#8220;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">lun show</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">&#8230;&#8221;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial"> command does not own the label information<BR>
and can only report the full capacity of the LUN.&nbsp; There is =
provision for a list of volumes owning the LUN to be displayed<BR>
as a future extension.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">The intent of the next phase would be to have a volume =
own LUN extents rather than entire LUNs.&nbsp; Which would<BR>
pave the way for multiple volumes in a LUN.&nbsp; Still have some =
details to resolve before that stage of</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">development</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Verdana">So when a &quot;volume show VOLNAME&quot; command is =
invoked, the size displayed against each LUN will be the sum of the =
sizes of the extents in use by the volume on that LUN (even if they are =
not contiguous)?</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Yes, that is correct.</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">&nbsp; However, this functionality is for the =
next phase of</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">development</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">.<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">I have several areas to =
refactor to eliminate the 1 LUN contains 1 VOLUME assumption.<BR>
LUN discovery is built with this assumption.&nbsp; =
Ditto</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> =
<FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">for =
auto-grow.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Verdana">When a volume is deleted do we intend to coalesce any =
LUN extents to obtain a single extent?&nbsp; If so will this affect our =
volume undelete feature?</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><BR>
</SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Verdana">When a volume is deleted, any extent used is marked =
free.&nbsp; Undelete walks the extents and<BR>
has to identify which ones were used by the volume for undelete.&nbsp; =
Now, if the LUN is used to<BR>
create a new volume, the</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Verdana">free</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Verdana">extents are</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Verdana">coalesced</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Verdana">.&nbsp; You cannot undelete after =
that.</FONT></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Verdana">Also how will adding new space to a LUN to a free LUN =
extent that previously contained a volume, affect our volume undelete =
feature?</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Now that is an interesting issue.</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">&nbsp; Currently, undeleted volume would come =
back as a bigger volume if it is the<BR>
last free extent.&nbsp; If it was not the last free extent, then it =
would come back with the same size.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Regards,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Jim</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<UL>
<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">Hello Jim,</FONT></SPAN></P>

<UL>
<DIV ALIGN=3DLEFT><LI><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">From reading the spec I understand you are making space =
appended to a physical LUN accessible by exporting them as partitions or =
as you call them, LUN extents.&nbsp; What would the device IDs for these =
partitions be as displayed by &quot;lun show =
disk&quot;?</FONT></SPAN></LI></DIV>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">There are various defined extent (aka volume) types =
define.&nbsp; Thus far, all we really do is give the allocated =
extent<BR>
to a volume.&nbsp; There are several details to be ironed out before =
multiple extents become extensively used.<BR>
That will be an issue for a future functional spec.&nbsp;&nbsp; Perhaps =
we should talk about future direction on this =
subject&#8230;</FONT></SPAN></P>

<DIV ALIGN=3DLEFT><LI><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">From the Figure 10 it would seem there is only a single =
owner block for the whole physical LUN.&nbsp; Does this mean that only a =
single node in a cluster can access the partitions at any given =
time.</FONT></SPAN></LI></DIV>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">The idea is to provide a well-known location for the =
owner block so outcluster access can be controlled as well =
as</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Limiting access by other nodes in the =
cluster.</FONT></SPAN></P>

<DIV ALIGN=3DLEFT><LI><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">If a partition has no FS on it, does it make to append =
space added to the physical LUN to be added directly to the =
partition?</FONT></SPAN></LI></DIV>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">At this time the last free extent of the LUN would own =
any expanded capacity added to a LUN.&nbsp; This is the up-side<BR>
of variable-size LUN extents.&nbsp; (The down-side is =
fragmentation.&nbsp; That becomes an issue once multiple extents<BR>
are being used.)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">&nbsp;If a volume was already created using the LUN, it =
would not suddenly get the new capacity.&nbsp; On down the road, =
auto-grow would be updated to allow the volume to grow into the expanded =
LUN capacity. This is fairly straight forward for a single LUN =
volume.&nbsp; A bit more complicated for a multi-lun volume.&nbsp;&nbsp; =
And I would think that customers would want a policy knob to control =
this behavior.</FONT></SPAN></P>

<DIV ALIGN=3DLEFT><LI><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Verdana">Regd Solaris disk-labels, AFAIK on an Intel based =
system Solaris creates a PC MBR, allocates the whole disk (skipping the =
1st track) to a primary partition of type 0x82 and slices that partition =
up using its native partitioning logic which I believe is very similar =
to the BSDs.&nbsp; So I believe we're safe on x86 systems running =
Solaris (which in turn means Leopards can co-exist with Cougars on the =
SAN?).</FONT></SPAN></LI></DIV>
<BR>
</UL>
<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Yes, if Sun honors PC MBR labels, then the new type-5 =
LUNs we can co-exist.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">This new label has lots of headroom for future =
growth,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">JIm</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C93619.8C0D18DD--
